src/test/java/org/example/visacasemanagementsystem/user/mapper/UserMapperTest.java (1)

39-44: Consider also asserting dto.id().

toDTO maps user.getId() into UserDTO.id, but the test never asserts it. Setting user.setId(...) in the arrange block and adding an assertThat(dto.id()).isEqualTo(...) would make the mapping contract fully covered and guard against accidental field-order regressions in the UserDTO record.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/mapper/UserMapperTest.java`
around lines 39 - 44, The test UserMapperTest does not assert that toDTO
preserves the user ID; update the arrange section to set user.setId(...) with a
known value and add an assertion in the assert block verifying dto.id() equals
that value (e.g., assertThat(dto.id()).isEqualTo(...)); this ensures the toDTO
mapping and the UserDTO.id field are covered and prevents regressions in
UserMapper.toDTO or the UserDTO record.

src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceIntegrationTest.java (2)

224-244: Minor: helpers bypass UserService and persist plaintext passwords.

Persisting "password123" directly to the DB is fine for tests and matches other suites, but note that createUser-path tests (line 35) go through passwordEncoder.encode(...) while update/delete/find tests read rows with plaintext passwords. If any future assertion checks the hashed password, this asymmetry will cause confusing failures. Consider encoding in the helper or routing through userService.createUser.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceIntegrationTest.java`
around lines 224 - 244, The helpers createAndSaveValidUser and createAndSaveUser
persist plaintext "password123" via userRepository, which bypasses UserService
password hashing; update these helpers to either call
userService.createUser(...) so the password is encoded through the normal flow,
or explicitly encode the password with passwordEncoder.encode("password123")
before saving with userRepository.save(...), ensuring tests that inspect stored
passwords see hashed values and stay consistent with createUser-path tests.

---

110-122: Test is order/seed-dependent.

findAll is asserted with hasSizeGreaterThanOrEqualTo(2). Because @Transactional on @SpringBootTest rolls back per test, this is safe in isolation, but any seed data (e.g. a data.sql or @Sql) will inflate the count and hide regressions where extra rows leak in. A stricter assertion using the two returned emails would be more precise:

Proposed fix

-        createAndSaveValidUser();
-        createAndSaveUser("Admin", UserAuthorization.ADMIN);
+        User u1 = createAndSaveValidUser();
+        User u2 = createAndSaveUser("Admin", UserAuthorization.ADMIN);
@@
-        assertThat(result).hasSizeGreaterThanOrEqualTo(2);
+        assertThat(result)
+                .extracting(UserDTO::email)
+                .contains(u1.getEmail(), u2.getEmail());

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceIntegrationTest.java`
around lines 110 - 122, The test findAll_shouldReturnAllUsers relies on a size
check which can be skewed by seeded data; instead capture the two users created
by createAndSaveValidUser() and createAndSaveUser("Admin",
UserAuthorization.ADMIN) and assert that userService.findAll() contains those
users (e.g. by extracting their email fields and asserting the returned list
contains both emails or containsExactlyInAnyOrder those two emails), so change
the assertion to verify the presence of the two specific created users rather
than a minimum list size.

src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceTest.java (1)

44-61: Unnecessary stub on userMapper.toEntity for the short-password test.

With MockitoExtension in strict mode, stubbing is fine here because the production code invokes userMapper.toEntity(dto) before the length check. Just flagging that if the service is later refactored to validate the password first (a sensible change), this stub will become a UnnecessaryStubbingException. Not blocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceTest.java`
around lines 44 - 61, The test stubs userMapper.toEntity(dto) unnecessarily for
createUser_shouldThrowIllegalArgumentException_WhenPasswordIsTooShort; remove
the when(userMapper.toEntity(dto)).thenReturn(new User()) line so the test only
asserts that userService.createUser(dto) throws and still
verifyNoInteractions(userRepository); if you need to keep a stub for other
reasons use Mockito.lenient() on the userMapper.toEntity stub or move that
stubbing into tests that exercise mapping logic.

src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceTest.java (2)

83-107: Assert the saved entity’s security-sensitive fields.

This test stubs password encoding but never proves the encoded password or forced USER authorization is saved. save(any(User.class)) would also pass if UserService saved the wrong instance.

Strengthen the assertion

         CreateUserDTO dto = new CreateUserDTO(
-                "New User", "new@test.com", "password123", UserAuthorization.USER
+                "New User", "new@test.com", "password123", UserAuthorization.SYSADMIN
         );
@@
         when(userMapper.toEntity(dto)).thenReturn(mappedUser);
         when(passwordEncoder.encode("password123")).thenReturn("encodedPassword");
-        when(userRepository.save(any(User.class))).thenReturn(savedUser);
+        when(userRepository.save(mappedUser)).thenReturn(savedUser);
         when(userMapper.toDTO(savedUser)).thenReturn(expectedDTO);
@@
         // Assert
         assertThat(result).isEqualTo(expectedDTO);
-        verify(userRepository, times(1)).save(any(User.class));
+        assertThat(mappedUser.getPassword()).isEqualTo("encodedPassword");
+        assertThat(mappedUser.getUserAuthorization()).isEqualTo(UserAuthorization.USER);
+        verify(passwordEncoder).encode("password123");
+        verify(userRepository).save(mappedUser);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceTest.java`
around lines 83 - 107, The test currently stubs passwordEncoder.encode and
userRepository.save but doesn't assert that UserService.createUser actually
saved a User with the encoded password and forced UserAuthorization.USER; update
the test for createUser to capture/verify the exact entity passed to
userRepository.save (use an ArgumentCaptor or verify with argThat) and assert
that the captured User's password equals the encoded value from
passwordEncoder.encode("password123") and that its authorization equals
UserAuthorization.USER; also ensure userMapper.toEntity(dto) and
userMapper.toDTO(savedUser) interactions remain verified so the flow is
validated.

---

184-205: Assert the entity role mutation, not only the mocked DTO.

userMapper.toDTO(targetUser) is mocked to return an ADMIN DTO, so this test can pass even if updateUserAuthorization() stops calling targetUser.setUserAuthorization(...).

Strengthen the assertion

         // Assert
+        assertThat(result).isEqualTo(expectedDTO);
+        assertThat(targetUser.getUserAuthorization()).isEqualTo(UserAuthorization.ADMIN);
         assertThat(result.userAuthorization()).isEqualTo(UserAuthorization.ADMIN);
         verify(userRepository).save(targetUser);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/visacasemanagementsystem/user/service/UserServiceTest.java`
around lines 184 - 205, The test currently only asserts the mocked UserDTO so it
can pass without the entity being mutated; after calling
userService.updateUserAuthorization(userId, UserAuthorization.ADMIN) assert the
actual entity mutation by checking targetUser.getUserAuthorization() (or capture
the saved entity via an ArgumentCaptor on userRepository.save and assert its
getUserAuthorization() is ADMIN) in addition to existing DTO assertion;
reference updateUserAuthorization, userService, targetUser, userRepository.save
and userMapper.toDTO when making the change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes